When you first install and start working with Docker Engine, Swarm mode isdisabled by default. When you enable Swarm mode, you work with the concept ofservices managed through the docker service command.

There are two ways to run the engine in Swarm mode:

When you run the engine in Swarm mode on your local machine, you can create andtest services based upon images you've created or other available images. Inyour production environment, Swarm mode provides a fault-tolerant platform withcluster management features to keep your services running and available.

These instructions assume you have installed the Docker Engine ona machine to serve as a manager node in your swarm.

If you haven't already, read through theSwarm mode key conceptsand try theSwarm mode tutorial.

When you run the command to create a swarm, Docker Engine starts running in Swarm mode.

Rundocker swarm initto create a single-node swarm on the current node. The engine sets up the swarmas follows:

The output for docker swarm init provides the connection command to use whenyou join new worker nodes to the swarm:

By default Swarm mode uses a default address pool 10.0.0.0/8 for global scope (overlay) networks. Everynetwork that does not have a subnet specified will have a subnet sequentially allocated from this pool. Insome circumstances it may be desirable to use a different default IP address pool for networks.

For example, if the default 10.0.0.0/8 range conflicts with already allocated address space in your network,then it is desirable to ensure that networks use a different range without requiring swarm users to specifyeach subnet with the --subnet command.

To configure custom default address pools, you must define pools at swarm initialization using the--default-addr-pool command line option. This command line option uses CIDR notation for defining the subnet mask.To create the custom address pool for Swarm, you must define at least one default address pool, and an optional default address pool subnet mask. For example, for the 10.0.0.0/27, use the value 27.

Docker allocates subnet addresses from the address ranges specified by the --default-addr-pool option. For example, a command line option --default-addr-pool 10.10.0.0/16 indicates that Docker will allocate subnets from that /16 address range. If --default-addr-pool-mask-len were unspecified or set explicitly to 24, this would result in 256 /24 networks of the form 10.10.X.0/24.

The subnet range comes from the --default-addr-pool, (such as 10.10.0.0/16). The size of 16 there represents the number of networks one can create within that default-addr-pool range. The --default-addr-pool option may occur multiple times with each option providing additional addresses for docker to use for overlay subnets.

The format of the command is:

The command to create a default IP address pool with a /16 (class B) for the 10.20.0.0 network looks like this:

The command to create a default IP address pool with a /16 (class B) for the 10.20.0.0 and 10.30.0.0 networks, and tocreate a subnet mask of /26 for each network looks like this:

In this example, docker network create -d overlay net1 will result in 10.20.0.0/26 as the allocated subnet for net1,and docker network create -d overlay net2 will result in 10.20.0.64/26 as the allocated subnet for net2. This continues untilall the subnets are exhausted.

Refer to the following pages for more information:

Manager nodes use an advertise address to allow other nodes in the swarm accessto the Swarmkit API and overlay networking. The other nodes on the swarm must beable to access the manager node on its advertise address.

If you don't specify an advertise address, Docker checks if the system has asingle IP address. If so, Docker uses the IP address with the listening port2377 by default. If the system has multiple IP addresses, you must specify thecorrect --advertise-addr to enable inter-manager communication and overlaynetworking:

You must also specify the --advertise-addr if the address where other nodesreach the first manager node is not the same address the manager sees as itsown. For instance, in a cloud setup that spans different regions, hosts haveboth internal addresses for access within the region and external addresses thatyou use for access from outside that region. In this case, specify the externaladdress with --advertise-addr so that the node can propagate that informationto other nodes that subsequently connect to it.

Refer to the docker swarm initCLI referencefor more detail on the advertise address.

Nodes require a secret token to join the swarm. The token for worker nodes isdifferent from the token for manager nodes. Nodes only use the join-token at themoment they join the swarm. Rotating the join token after a node has alreadyjoined a swarm does not affect the node's swarm membership. Token rotationensures an old token cannot be used by any new nodes attempting to join theswarm.

To retrieve the join command including the join token for worker nodes, run:

To view the join command and token for manager nodes, run:

Pass the --quiet flag to print only the token:

Be careful with the join tokens because they are the secrets necessary to jointhe swarm. In particular, checking a secret into version control is a badpractice because it would allow anyone with access to the application sourcecode to add new nodes to the swarm. Manager tokens are especially sensitivebecause they allow a new manager node to join and gain control over the wholeswarm.

We recommend that you rotate the join tokens in the following circumstances:

Additionally, it is a best practice to implement a regular rotation schedule forany secret including swarm join tokens. We recommend that you rotate your tokensat least every 6 months.

Run swarm join-token --rotate to invalidate the old token and generate a newtoken. Specify whether you want to rotate the token for worker or managernodes: